This invention relates generally to the field of computer systems, and, more particularly, to the use of input devices with software applications.
Various input devices are available to permit a computer user to communicate with a computer. A typical personal computer offers input devices such as a keyboard and a mouse. Numerous other devices are available, such as drawing pads, joysticks, and steering wheels (for use with driving games). These devices can be connected to a computer, and they permit the user to communicate information to the computer; the information communicated instructs software applications running on the computer to perform specified actions. Ideally, a computer user would be able to load a software application, connect an appropriate device to the computer, and the device and software would work together naturally. This ideal, however, has not been realized in prior systems.
In order for a device to work with a given software application, there must be a defined relationship between the controls on the device and actions that the software performs, but there are few standards governing the way in which this relationship is defined. Traditionally, software developers design software applications to support the most common devices and provide a device mapping control panel for those users who own other devices. This approach, however, has drawbacks: A software developer who wants to design an application to work well with many devices must know what controls are available on each device (e.g., buttons, levers, etc.) and how the device notifies the computer system of operational events (e.g., an input of 1001 signifies the pressing of a button). Additionally, the software developer must make design decisions as to which devices the software will support, and, on those devices that will be supported, how the controls will map to the actions that the software performs, which is a labor-intensive process for the software developer. Moreover, if a user owns an unsupported device, the user must generally resort to mapping the unsupported device manually by referring to generic pictures and tables in an application""s manual and using the device mapping control panel provided with the application, which is a notoriously difficult process.
Some input device manufacturers address the problem of ensuring that specific applications work well with the device by supplying a software component with the device that dynamically reconfigures the device based on guesses as to what actions the application expects the device to support. Some manufacturers of devices with newer features provide filters to accommodate existing applications; frequently, these filters simulate keyboard presses or mouse movements for games that do not recognize enhanced features of the new device. Alternatively, some devices are supplied with mapping software that detects the presence of certain applications on the system and configures the device to work better with those applications. These ad hoc approaches, however, are error prone, may result in a relationship between device controls and software actions that feels unnatural to the user, and can only provide support for applications the device manufacturer knows about and chooses to support.
In view of the foregoing, there is a need for a system that overcomes the drawbacks of the prior art.
The system of the present invention includes an input device mapper, which links controls on input devices with actions that a software application performs. The input device mapper provides vocabularies of semantics, called xe2x80x9cgenres,xe2x80x9d where the semantics in each genre are appropriate for a particular category of applications, such as driving games or flight simulation games. For each input device, a correlation is provided to the input device mapper between the device""s controls and semantics selected from a genre. Also, for each software application, a correlation is provided to the input device mapper between the application""s actions and semantics selected from a genre. The input device mapper creates a mapping between device controls and software actions by identifying an input device that supports the software""s genre and by connecting, as closely as possible, each control on the device with a software action that is correlated with the same semantic.
Game applications exemplify the system""s use. For example, there may be a xe2x80x9cdriving gamexe2x80x9d genre. Each semantic in the driving game genre represents an abstract action that a driving game may be able to perform, such as xe2x80x9csteer,xe2x80x9d xe2x80x9caccelerate,xe2x80x9d and xe2x80x9cdecelerate.xe2x80x9d A steering wheel device may correlate the xe2x80x9csteerxe2x80x9d semantic with turning the steering wheel, and the xe2x80x9cacceleratexe2x80x9d and xe2x80x9cdeceleratexe2x80x9d semantics with the right and left pedals. A driving game application may correlate the xe2x80x9csteer,xe2x80x9d xe2x80x9caccelerate,xe2x80x9d and xe2x80x9cbrakexe2x80x9d semantics with the game actions of turning, speeding up, and slowing down, respectively. These correlations are provided to an input device mapper, which maps each device control into the game action associated with the same semantic. The input device mapper uses these correlations to map device controls into software actions; for example, the steering wheel maps to the action of turning the car, and the right and left pedals map to the actions of speeding up and slowing down the car.
The system may include several genres, where the different genres are appropriate for different types of applications. For example, in addition to the driving game genre described above, there could be a flight-simulation genre and a computer-aided design (CAD) genre. Devices may specify which genres they work well with and may provide a correlation between their controls and the semantics from each such genre. An application, on the other hand, can specify which genre the application falls into, or may specify various genres, representing different contexts within the application. For example, a game may start out in a driving game genre while a character drives to the location of a mission; later, the game may switch to a first-person fighter genre for when the character gets out of the car and moves around fighting targets.
The mapping created by the input device mapper may be used by an input device manager, which translates notification of device events (such as the pressing of a button on a joystick) into the application""s input dialect while the application executes. Alternatively, the input device mapper may provide the mapping directly to the application, which then receives event notifications directly from the various input devices and uses the mapping to perform a particular action upon receiving notification of a corresponding device event, as specified in the mapping.
Other features of the invention are described below.